Add deployment-managed core migration primitives - #2437

Pull request overview

Adds the core building blocks for deployment-managed core database migrations in packages/core, including a runtime policy (auto/check/manual), a validated secret-free migration manifest written at build/sync time, direct migration executors for SQLite/libSQL/Postgres, and public exports (identity + exact status) intended for deployment tooling.

Changes:

• Introduces runtime migration modes and enforces them during runtime initialization + middleware handling.
• Adds migration manifest primitives (identity, manifest schema/validation, manifest writer, config loader, integration metadata) and writes .emdash/migrations.json during astro build/astro sync.
• Adds direct migration executors for SQLite/libSQL/Postgres plus a new exact migration status API (knownApplied/pending/unknownApplied) with broad test coverage.

Reviewed changes

Copilot reviewed 50 out of 51 changed files in this pull request and generated 1 comment.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

This PR introduces a well-scoped set of deployment-managed migration primitives: a runtime migration policy (auto/check/manual), build-time manifest generation and writing, identity/fingerprinting, and direct SQLite/libSQL/PostgreSQL executors. The approach fits EmDash’s architecture—writer runs at Astro build/sync time, executors are loaded from the same published subpaths used by the runtime, and the runtime enforces the policy without adding queries to the logged-out hot path beyond the existing migration fast-path count.

I read the new migration source, the adapter migration entrypoints, the integration wiring, the runtime policy integration, the Virtual-module type updates, the package exports, tsdown entries, and the test coverage. The code is generally clean, uses Kysely for SQL safety, keeps credentials out of the build artifact, and adds real behavioral tests for check/apply, secret rejection, target fingerprinting, config loading, and manual-mode middleware behavior.

One real logic bug stands out: the direct executor discards a successful migration report if closing the dialect fails. I also have one minor testing nit about a hard-coded SHA fingerprint literal.

This PR adds a well-scoped set of deployment-managed migration primitives: a runtime migration policy (auto/check/manual), build-time manifest generation and writing, migration identity/fingerprinting, and direct SQLite/libSQL/PostgreSQL executors loaded from the same published subpaths the runtime uses. The approach fits EmDash’s architecture—writer runs at Astro build/sync time, the runtime enforces the policy without new logged-out hot-path queries beyond the existing migration fast-path count, and credentials are kept out of the build artifact. It links to the approved Discussion (#2418) and includes changesets, tests, and the necessary package/tsdown entries.

I read the new migration source, the adapter entrypoints, the integration and middleware wiring, the runtime policy integration, the Virtual-module type updates, the package exports, tsdown entries, and the test coverage. This is a static review; I did not run the test suite or build.

Prior-review status:

• ✅ Fixed: the direct executor no longer discards a successful migration report when closing the dialect fails; it now returns the report while logging the close error.
• 🔁 Still open: the hard-coded SHA-256 fingerprint literal in identity.test.ts remains.

New finding: the middleware’s 503 response tells operators to run emdash migrate, but the EmDash CLI does not expose a migrate subcommand yet. That guidance is currently unfulfilled and will confuse operators when check or manual mode blocks traffic.

Verdict: comment — one real needs_fixing issue (the CLI message), one testing suggestion, and otherwise a clean, deliberate implementation.

This is a re-review of the deployment-managed migration primitives PR (#2437). The implementation remains the right shape for #2276/#2418: the build-time manifest keeps secrets out of the artifact, auto/check/manual modes are wired into the existing runtime and middleware path without adding logged-out hot-path queries, and the direct SQLite/libSQL/PostgreSQL executors reuse the same published adapter subpaths as production.

I re-read the migration identity, manifest builder/writer, direct executor, policy, integration wiring, runtime policy integration, middleware 503 paths, and the new/updated tests. Conventions still look good: SQL is parameterized/identifier-safe, the manifest secret-free validator rejects credentials and connection URLs, the setup probe is now gated to auto mode so the query-count snapshot stays unchanged, changesets are present and user-facing, and no admin UI strings were added.

The only unresolved issue from the previous review is still present: the fingerprint test hard-codes a SHA-256 literal. That assertion is a config-pin test that restates the implementation and cannot fail on any real regression other than an intentional algorithm change. The preceding assertions already cover determinism (expect(second).toBe(first)) and hex formatting (expect(first).toMatch(/^[0-9a-f]{64}$/)), so the literal should be removed.

No new security, data-integrity, or logged-out query regressions were introduced.